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REPLY TO OFFICE ACTION 

AMENDMENTS TO THE DRAWINGS 

A new FIG. 3 A is submitted to include reference character 312, mentioned in the 

Specification, to the bits in the row corresponding to "File Type / Access Permissions". 
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REMARKS 

The examiner is thanked for the performance of a thorough search. In this reply, Claims 
1, 3, 4, 8-10, 12, 13, 17, 18, 20, and 21 are amended. Claims 22-38 are canceled. New claims 
39-59 are presented. Hence, Claims 1-21 and 39-59 are pending in the application. 

The amendments to the claims as indicated herein do not add any new matter to this 
application. Furthermore, amendments made to the claims as indicated herein have been made to 
exclusively improve readability and clarity of the claims, not for the purpose of overcoming 
alleged prior art. Each issue raised in the Office Action mailed May 2, 2006 is addressed 
hereinafter. 

I. NEW CLAIMS 

New Claims 39-55 are similar in scope to Claims 1-17 and present subject matter similar 
to Claims 1-17 but in computer-readable medium format. New Claims 56-59 are similar in 
scope to Claims 1-3 and 5 and present subject matter similar to Claims 1-3 and 5 but in apparatus 
format. 

II. ISSUES NOT RELATING TO PRIOR ART 
A. DRAWINGS 

The drawings stand objected to as failing to comply with 37 CFR 1.84(p)(5). The 
description has been amended (above) to indicate reference character 612. The description 
already mentions reference character 312 in paragraphs 73 and 74 of the application. There, the 
description states: "For example, the process reads or otherwise receives the file type/access 
permissions bits 312 of inode 310 of FIG. 3 A. The permissions bits 312...." (emphasis added). 
Reconsideration of the drawings is respectfully requested. 
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B. SPECIFICATION - ABSTRACT 

The abstract of the disclosure stands objected to because the length exceeds 150 words. 
The abstract has been appropriately amended. Reconsideration is respectfully requested. 

C. CLAIMS 3, 6, 12, 15, AND 20 

Claims 3, 6, 12, 15, and 20 were rejected under 35 U.S.C. § 1 12(2) as allegedly 
indefinite. 

Regarding Claim 3, it is allegedly unclear whether "an access identifier" is intended to be 
the same as or different from "access identifier" in Claim 1 . By referring to "the step of creating 
an access identifier.. ." in line 2 of Claim 3, it is clear that this statement is referring to the step of 
"creating an access identifier. . ." recited in line 10 of Claim 1 . 

Also, regarding Claim 3, it is allegedly unclear whether "a group identifier file attribute" 
recited in lines 3-4 of Claim 3 is intended to be the same or different than "a group identifier 
attribute" recited in line 7 of Claim 3. Applicant respectfully disagrees. The phrase "group 
identifier attribute" is introduced with the article "a" indicating that it is different than any 
feature mentioned previously in Claim 3 and Claim 1. Further, "group identifier file attribute" is 
an attribute of a file, whereas Claim 3 recites that the "group identifier attribute" is an attribute of 
an Operating System process. Existing language of the claims as well as paragraph 36 of the 
Specification makes the foregoing distinction clear. Claims 12 and 20 were similarly rejected. 
Therefore, reconsideration of Claims 3, 12, and 20 is respectfully requested. 

Regarding Claim 6, the Office Action asserted that it is unclear whether "a file operation" 
in line 3 of Claim 6 is intended to be the same or different from "an operation on the file" recited 
in line 13 of Claim 1. Claim 15 was similarly rejected. Claims 6 and 15 have been appropriately 
amended. Reconsideration of Claims 6 and 15 is respectfully requested. 
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III. ISSUES RELATING TO PRIOR ART 

Claims 1-38 stand are rejected under 35 U.S.C. § 102(b) as allegedly anticipated by U.S. 
Pat. No. 6,202,066 Bl issued to Barkley et al. ("Barkley"). The rejection is respectfully 
traversed. 

A. CLAIM 1— BARKLEY ET AL. 

An anticipation rejection under 35 U.S.C. § 102 is overcome by a showing that the 

applicant's claims include at least one feature that is not shown, described or taught in the cited 

prior art reference, explicitly or by inherency. Barkley does not teach or suggest all features of 

amended Claim 1. Claim 1 recites: 

A method for controlling access to a resource, the method comprising the steps of: 
creating and storing in a filesystem of an Operating System a file that represents the 
resource; 

receiving user-identifying information from a user requesting access to the resource, 
wherein the user-identifying information comprises a role associated with the 
user, wherein the role is determined from a user identifier uniquely associated 
with the user and from a group identifier associated with a group that includes the 
user; 

receiving a resource identifier associated with the resource; 

creating an access identifier based on the user-identifying information and the 

resource identifier, wherein the access identifier is formatted as a file attribute 

that is used by the Operating System to manage file access; 
calling the Operating System to perform an operation on the file using the access 

identifier to gain access to the file; and 
granting the user access to the resource only if the Operating System call successfully 

performs the operation, (emphasis added) 

The Office Action contends that the fifth step of Claim 1, "calling the Operating System 
to perform an operation on the file using the access identifier to gain access to the file" is found 
in Barkley at col. 8, lines 25-38. However, that portion of Barkley states that a management 
software tool (i.e. RGP-Admin) manages Object Access Types (OATs) and writes permissions 
and users associated with each object to access control lists (col. 8, lines 25-28). The remainder 
of that portion of Barkley states: 
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the OAT in this implementation serves as a highly sophisticated mechanism for 
maintaining the conventional ACLs of all the objects assigned to the OAT. However, the 
OATs could be implemented in different ways; for example, ACLs treated as separate 
portions of the object (i.e., as conventional) could be dispensed with completely, and 
access to a given object permitted only if an OAT assigned to that object itself indicated 
that the requestor was a member of a role having been assigned the permission sought 
with respect to the object. 
The entire reference of Barkley fails to teach or suggest that an Operating System is called to 

perform an operation on a file. In fact, the cited portion of Barkley does not even state that an 

operation is performed on the file. Barkley merely states that access is permitted to an object 

depending on the OAT associated with that object. Barkley says that RGP- Admin is a 

"management software tool," which anyone of skill in the art would understand to be an 

application program, not an OS. Thus, Barkley fails to teach that an Operating System performs 

an operation a file. 

Furthermore, the "file" of Claim 1 is neither the "object", "resource", nor "file" of 
Barkley. Claim 1 recites: "creating and storing in a filesystem of an Operating System a file that 
represents the resource" (emphasis added). The portions of Barkley cited in the Office Action 
state: "object security attributes are usually kept with the object (e.g. in the header of a file) and 
the object resides in (or a resource is accessed through) a single server"; and "OATs can be 
created, edited, deleted, and assigned to or removed from objects". It is unclear what in Barkley 
the Office Action is analogizing to "file" in Claim 1. Perhaps the Office Action is analogizing an 
OAT to a "file" of Claim 1. However, Barkley states that an OAT is associated with one or more 
objects or resources, but an OAT does not represent an object or resource. Rather, "OATs 
comprises access control specifications associating roles with permissions, and associating the 
roles with a set of objects, such as resources or files." (Abstract). Perhaps, the Office Action is 
analogizing "object security attributes" of Barkley with a "file" of Claim 1. In that case, the 
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portion of Barkley mentioned previously (i.e. col. 8, lines 25-38) would have to teach or suggest 

that an Operating System performs an operation on object security attributes, which it does not. 

Therefore, Barkley fails to disclose "creating and storing in a filesystem of an Operating System 

a file that represents a resource." 

The Office Action further contends that Barkley shows "receiving a resource identifier 
associated with the resource 55 at co. 1, lines 22-27 and col. 7 lines 22-26. Those portions of 
Barkley together equate "objects 55 and "resources 55 and define an OAT as providing "a 
mechanism for mapping permissions authorized with respect to various objects to the 
corresponding identified individuals or groups. 55 Therefore, the Office Action correlates an OAT 
of Barkley with the "resource identifier 55 of Claim 1. However, the Office Action then 
apparently correlates an OAT with the "access identifier 55 of Claim 1 when the Office Action 
cites col. 4, lines 59-60 for disclosing "creating an access identifier based on the user- 
identifying information and the resource identifier 55 (emphasis added). Thus, the Office 
Action makes the OAT of Barkley perform double-duty by acting as both a resource identifier 
and an access identifier. However, an access identifier is based on both user-identifying 
information and a resource identifier. Therefore, the Office Action has failed to show at least 
one of "receiving a resource identifier associated with a resource 55 and "creating an access 
identifier based on the user-identifying information and the resource identifier." 

The Office Action also contends that Barkley discloses "wherein the access identifier is 
formatted as a file attribute that is used by the Operating System to manage file access 55 at col. 2, 
lines 23-26 and col. 4, lines 59-60. Again, the Office Action apparently correlates an OAT of 
Barkley with an "access identifier" of Claim 1. However, an OAT, as disclosed in Barkley, is 
not formatted as an attribute of a file, but rather is separate from an object or file (col. 4, lines 57- 
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59). Furthermore, Barkley does not even mention how an OAT is formatted, much less that an 

OAT is formatted. 

At least one rationale for Applicant's approach is to avoid having to implement complex 
RBAC security mechanisms that require application software developers to learn a specific API 
and write code against it (paragraph 3 of the application). On the other hand, the facilities of an 
Operating System filesystem to control access to and perform operations on files are well-known 
and application software developers routinely use them (paragraph 5). Such facilities include a 
library of system calls and a number of well-known APIs (paragraph 5). By using the Operating 
System to perform operations on a file, a complex RBAC security mechanism is not required. 
Therefore, Claim 1 recites that the Operating System is called to perform an operation on the 
file using the access identifier. 

Barkley, on the other hand, neither teaches nor suggests that an Operating System is 
called to perform an operation on a file. Thus, implementation of Barkley requires a complex 
security mechanism and a specific API in which software developers would have to learn and 
write against. Indeed, Barkley states: "the OAT in this implementation serves as a highly 
sophisticated mechanism" (col. 8, lines 29-30), thus teaching away from a mechanism that may 
use native Operating System routines and calls. 

Based on the foregoing, Barkley fails to teach or suggest all the features of Claim 1 . 
Therefore, removal of the rejection under 35 U.S.C. § 102(b) is respectfully requested. 

B. CLAIMS 10, 18, 39, 48, AND 56 

The Office Action stated the same reasons in rejecting Claims 10 and 18 to those in 
rejecting present Claim 1 . Also, Claims 39, 48 and 56 recite features discussed above that make 
Claim 1 patentable over Barkley. Therefore, for at least the same reasons set forth above by the 
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Applicant in connection with present Claim 1, it is respectfully submitted that each of Claims 10, 
18, 39, 48 and 56 is patentable over Barkley under 35 U.S.C. § 102(b). 
C. DEPENDENT CLAIMS 

The dependent claims not discussed thus far are dependent claims, each of which depends 
(directly or indirectly) on one of the independent claims discussed above. Each of the dependent 
claims is therefore allowable for the reasons given above for the claim on which it depends. In 
addition, each of the dependent claims introduces one or more additional limitations that 
independently render it patentable. However, due to the fundamental differences already 
identified, to expedite the positive resolution of this case, a separate discussion of those 
limitations is not included at this time. The Applicant reserves the right to further point out the 
differences between the cited art and the novel features recited in the dependent claims. 
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IV. CONCLUSIONS & MISCELLANEOUS 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. The Examiner is invited to contact the undersigned by 
telephone regarding any issue that would advance examination of the present application. 

No fee is believed to be due for this paper. If any applicable fee is missing, throughout 
the pendency of this application the Commissioner is authorized to charge any applicable fee to 
Deposit Account No. 50-1302. 



Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 



Dated: August 1.2006 
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